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ABSTRACT 


The focTis of this thesis is to review, and determine the development of, 
currently installed automated financial management information ^sterns at Navy 
field activity comptroller departments that operate tmder the Navy’s Resource 
Management System. Based upon the findings, develop a guide for use by 
comptroller departments in the development of an automated fmancial management 
information system. The resulting guide will be included in the Practical 
ComptroUership Covirse and Financial Management in the Armed Forces Course 
Textbook, offered by the Navy Postgraduate School in Monterey, California. 
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I. INTRODUCTION 


A. DISCUSSION 

The Department of the Navy has assigned the responsibilities of managing 
appropriated funds down to the level of the Commanding Officer of a unit. 
Accountability for managing financial resources is established by federal law 
(Title 31 United States Code). Specifically, Title 31 of the U.S. Code on "Money 
and Finance" has two sections that directly influence the use of appropriated 
funds. Title 31 U.S. Code Section 1301 requires that appropriated funds be 
obligated for the intended purpose that Congress specifies. And, Title 31 U.S. 
Code Section 1517 prohibits any government employee from obligating in excess 
of the amoxmt authorized. A violator of Title 31 Section 1301 or 1517, either 
willfully or xmknowingly, is subject to disciplinary action or criminal penalties. 
[Ref. l:p. A22, 2:p. 10] 

Congress has sent out a clear message to all DoD activities with passage of 
Title 31 U.S. Code. That is, all activities must manage their financial resources 
accurately enough to ensure that all appropriated fimds are obligated in a 
manner to prevent a violation of Title 31. To do this, an activity must be able to 
recognize it’s financial position and be able to monitor it’s progress while 
executing the activity fin a n c i al plan. Without this capability, it is difficult for an 
activity to manage it’s resources effectively and not incur a Title 31 violation. 

This highlights the importance of an effective Financial Management Information 
System (FMIS). A FMIS needs to be able to provide the needed information to 
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management, so that a manager can effectively allocate available funds and at the 
same time meet the requirements set forth by Congress. 

B. OPERATING ENVIRONMENT 

1. Soiurce of Appropriated Funds 

The Navy Comptroller (NAVCOMPT) is responsible for the financial 
management of appropriated funds allocated to the Department of the Navy 
(DoN). NAVCOMPT receives funds from the Secretary of the Navy, and 
distributes these fimds to nu^or claimants. A mqjor claimant is a 
bureau/office/command/headquarters that is designated as an administering 
office. And is assigned specific budgeting, accounting, reporting, and budget 
execution responsibility. Subclaimants are commands designated to receive a 
subclaimant operating budget from a nuyor claimant. [Kef. l:p. B21] 

Mfgor/sub claimants redistribute funds to responsibility centers (i.e., 
shore commands) via allotments. An allotment is the authority, expressing a 
specific amoimt of funds, for an activity to commit, obligate, and expend funds 
for a specified purpose. An allotment is provided to the activity by NAVCOMPT 
Form 2168-1 Resource Authorization. In addition to the funds, the NAVCOMPT 
2168-1 also specifies the legal limitations and restrictions placed on the funds. 

The responsibility center is the lowest level in an organization that the 
legal responsibility under Title 31 can be assigned. The Commanding Officer of 
a responsibility center retains the full legal responsibility under Title 31. A 
responsibility center further divides the allotment into operating targets 
(OPTARS). OPTARs are administrative redistributions of funds to the 
departments or divisions, called "cost centers", within a responsibility center. 
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Cost centers operate within a set of policies and procedures, 
established by a responsibility center, to control the obligation of funds. While 
cost centers are not directly subject to Title 31, an inadequate system of 
administrative controls on the use of OPTAR funds can lead to an over obligation 
of funds at the activity level, thus exposing the responsibility center to a 
violation of Title 31. 

2. Accounting System 

A Financial Information Processing Center (FIPC) is an activity that is 
assigned the task of performing official accoimting and disbursing for a 
responsibility center, including maintaining official accounting records, civilian 
payroll, and bill paying. 

The FIPC is a disinterested third party that consolidates financial 
transactions, and provides official accounting reports to higher authority (i.e., 
mqjor/sub claunant). Mqjor/sub claimants depend primarily on these official 
accounting reports to evaluate budget execution performance of a responsibility 
center. Throughout the year, the mqjor claimant reviews the responsibility 
center’s obligation rates, unliquidated obligations, and unmatched expenditure 
rates to determine whether to recoup or grant additional funds. 

A responsibility center that receives Operations and Maintenance 
Appropriation (0,M&N) allotments, operate imder the Navy’s Resomce 
Management System (RMS). RMS is the formal Navy system that tracks and 
accounts for financial resources assigned to responsibility centers. A 
Responsibility center that operates under RMS is referred to as an RMS activity. 

Responsibility centers and cost centers each maintain local accoimting 
records called "memorandum accounts". The memorandum accoimts are 
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maintained to monitor the use of funds, and are the source documents for the 
reconciliation against official FEPC records. They are not recognized as the 
official records because they are not directly visible to the m^or/sub claimant. 
[Ref. 2: p. 211 

3. Integrated Disbursing and Accounting System 

The Navy Accounting and Finance Center (NAFC) in Washington, 

D.C. was designated as the project office for the Integrated Disbursing and 
Accounting system (IDA). NAFC, was to develop an automated system that 
wovdd consolidate and standardize Navy accoimting practices. In October 1989 
DoN was notified that the Secretary of Defense was reviewing the issue of a 
standardized Department of Defense (DoD) integrated accounting system. In 
December 1989, as a result of this review, fiirther development of all accounting 
systems, including IDA, have been cancelled. IDA will ultimately be replaced 
with a DoD accounting system. 

IDA is the automated accounting system that is operated by the 
FIPC’s. With the cancellation of the IDA project, the intended consolidation and 
standardization of the various automated ^sterns at the different FIPC’s will not 
be completed. Therefore, field activities will have to operate the currently in- 
place, not fully developed, IDA system until the new DoD system comes on line. 

4. Official Accounting System vs. Unofficial Accounting Sj^tems 

There are two reasons for maintaining unofficial accounting records at 
the activity level. First, the IDA accounting ^stem is never up-to-date [Ref. 

6:pp. 5-6]. There is a lag between the time an obligation is created and when 
the IDA system posts the transaction. This delay is due to IDA being a batch 
oriented processing system. (Ultimately the final version of IDA was to resolve 
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this problem by going to an on-line system.) Therefore, the current IDA system 
does not provide real-time accovmt balances. 

Second, the IDA accoxmting system is inaccxirate. These inaccmacies 
can be attributed to hximan input errors at either the FIPC or at the local 
command. Presently the only way to identify and reconcile these errors is with a 
second accounting system. [Ref. 2:pp. 27-301 

The second imoflicial accoimting system exists at the cost center level. 
The cost centers have the same motivations as the Comptroller to maintflin 
their own accounting records. These accounting records are unofficial but vital. 
The cost centers are routinely tasked by the Comptroller to reconcile transaction 
Ustings and research discrepancies. Cost centers also have the need to know 
their current OPTAR balance on a daily basis. 

All three accoimting systems are necessary to be able to keep track 
and maintain accurate financial accounts. The rn^or claimant recognizes the EDA 
records and account balances, which in-tum requires the shore command to 
ensure that IDA is accurate. There will always be two unofficial accounting 
systems within the commands to support and validate the official system, and to 
meet their internal f in a n cial management information needs. 

C. PURPOSE OF RESEARCH 

The primary purposes are: to determine what attributes should be 
incorporated in a Navy shore activity’s Automated Financial Management 
Information System (AFMIS); review currently installed AFMIS’s at Navy shore 
activities; and develop an information guide on AFMIS’s for Comptrollers. The 
guide is to be used in the Practical Comptrollership course and Financial 
Management in the Armed Forces course at the Navy Post Graduate School. 
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D. SCOPE OF RESEARCH 

The thesis will provide information as to what shoiild be expected from a 
Navy shore command’s AFMIS in addition to addressing the following research 
questions; 

• Do instructions/directives exist for providing guidance to Navy shore 
activity Comptroller’s, in the development of a local AFMIS? 

• Is there a need for further/improved guidance to be provided by the Navy 
Comptroller in regard to Navy shore activity Comptroller’s AFMIS? 

• What AFMIS’s are currently in place at Navy shore activities, and, what are 
their features? 

• How were the AFMIS’s developed? 

• Are there RMS activities AFMIS’s similarities, and if so, how did these 
similarities come to be? 

• What featxires should be incorporated into a Navy shore activity AFMIS? 

• Should Navy shore activity AFMIS’s be compatible with other activities? 

Navy Comptrollers are tasked with a significant number of administrative 
requirements, of which many could be automated. It is not the intent of this 
thesis to address all areas in a comptroller department that lend themselves to 
automation. 

E. RESEARCH APPROACH 

The research for this thesis was conducted in two phases. The first phase 
was to determine what financial information should be reviewed by RMS 
activities management. This phase of the research entailed a thorough review of 
pertinent publications, and establishing a liaison with several key individuals in 
the Navy Comptroller Organization. Initially, the task was to determine what 
the typical Comptroller at a Navy shore activity should have in his/her AFMIS. 
Information was obtained via interviews from the following commands: 
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• Commander, Navy Accounting and Finance Center, Washington, D.C. 
(NAFC) 

• Commander, Naval Surface Force, U. S. Pacific Fleet (COMNAVSURFPAC) 

• Commander, Fleet Accounting and Disbursing Center, Atlantic (FADCLANT) 

• Commander, Fleet Accounting and Disbursing Center, Pacific (FADCPAC) 

• Naval Electronics Command, San Diego 

Once it was determined as to what the AFMIS shovild consist of, it was 
necessary to obtain a sotind understanding of the IDA system. Two intended 
featmes of IDA were to provide an AFMIS through a fourth generation language 
report generator. And, IDA was to evolve into an on-line processing system, in 
place of the cxirrent batch oriented processing system [Ref. 3;p. 15]. Information 
on IDA was obtained from the Requirements and Specification documents for the 
IDA system and via interviews with key NAFC personnel that were involved with 
the development of IDA 

The second phase entailed visiting selected RMS activities to address the 
research questions. Five RMS activities were reviewed. 

The field research consisted of independent interviews with the 
Comptroller, Budgeting Supervisor, and the Accoimting Supervisor at each 
activity. The intentions of the interviews where four fold: 

• Determine what automated FMIS is currently in place. 

• Determine the hardware and software configuration cvirrently in place. 

• Determine their methodology as to how they developed their current 
system. 

• Determine what guidance was available to assist shore RMS activities in the 
development effort of an AFMIS. 
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The interview process was a seixii-structured process. The interviews entailed 
using a predesigned interview form to ensure that all research questions were 
addressed in a manner that they could be compared between the different RMS 
activities [Ref. 4:p. 111]. 

F. THESIS FORMAT 

The structure of this thesis consists of two primary section” Chapters 1 
through 4 and Appendix A address the research methodology, what attributes an 
AFMIS should have, findings, conclusions, and the recommended financial 
management information system charts/reports, respectively. Appendix B is a 
supplemental section to the Practical Comptrollership Course and Financial 
Management of the Armed Forces Student Textbook. It provides both 
background and guidance for comptrollers that are considering the automation of 
their BTVUS’s. 
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11. MANAGEMENT INFORMATION 


A. INFORMATION NEEDS 

Without having the right information at the right time, a manager is 
unable to carry out his/her responsibilities effectively. Information m\ist be "the" 
information that a manager needs for the particular decision making process that 
he/she is encountering. And, the information must be timely. Timeliness is 
crucial, receiving the information when there is not adeqiiate time for the 
manager to take advantage of a sitiiation, or to correct a problem is 
unacceptable. 

In any given situation, managers have different ideas as to what information 
is needed, and when. The variances stem from some managers having a better 
feel for a particular situation, or maybe having a better understanding as to what 
information is most relevant. The level of experience of the manager will also 
impact the managers information requirements. Depending on the level of 
diversity in the organization and the dynamics of the business routine, 
information requirements could range from a very stable (a very ^stematic and 
well established routine), to a very dynamic organization that has continually 
changing information requirements. 

Management has seven types of information requirements: [Ref. 5:pp. 32- 
34] 

1) Comfort information: information that will tell a Comptroller if the 
organization’s performance is acceptably close to planned performance. 

2) Status information: information that helps managers to monitor projects 
or resolution of problems. For example, tracking the obligation rate in 
preparation for the Mid-Year Review. 
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3) Warning information: information that tells management that a problem 
might be encountered. For example, information that shows higher then 
usual overtime usage, or exceeding the projected obligation rate. 

4) Planning information: information that helps an organization to determine 
what the objectives should be and how to achieve them. For example, in the 
budgeting process, the information that is gathered over the previous fiscal 
year, current fiscal year, and proposed budget requests from the various cost 
centers wovdd be planning information. 

5) Internal Operations information: indicators of internal organization 
performance compared to expectations 

6) External Intelligence information: information provided from other sources 
outside an organization. This could be as formal as a Navcompt 2168-1 
Resource Authorization document, or unofficial as a call on the telephone 
giving a command advance notification that there is a change in a mission 
area that will impact its financial projections. 

7) Externally Distributed information: information that is being provided to 
interested parties outside an organization. For example, the TVpe Commander 
(TYCOM) reviews an activity’s financial status based upon the information 
provided by the FIPC. 

These seven types of information might be similar in some situations, but 
different in others. Information is generated to meet several different 
management needs. For the most part these information requirements are 
predictable, but must be flexible to meet the cmrent sitxiation. 


B. COMPTROLLER MANAGEMENT INFORMATION REQUIREMENTS 

When trying to identify the management information that is required to 
support a shore RMS activity, three questions need to be answered: 1) What 
mformation should be reported to the users (i.e.. Commanding Officer, Executive 
Officer, Department Heads, and Comptroller) so that they can effectively execute 
the responsibilities of their office? 2) How should the information be 
presented? The method of presentation can directly affect how management will 
interpret the information, and the amount of effort required in reviewing the 
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information. 3) How often should the information be presented? Should 
management review every report on a weekly basis? Or, should they review only 
selected reports on a periodic basis. Should exception reporting be used? The 
latter two questions are addressed first, followed by the minimum management 
information that is required in an AFMIS. 

1. How the Information Should he Presented 

Navy RMS activity financial managers are faced with the challenge of 
keeping abreast of all financial accounts, appropriations, and special interest 
items. They must be able to review these various areas in the most efficient 
manner possible. The trend in the commercial sector has been towards the use 
of graphical presentations in reviewing management information. In 1986, 67 
percent of all reviewed MIS’s used computer graphics. Graphics, if presented 
properly, have the ability to depict trends more clearly to management compared 
with the same information that is displayed in a column format in a report. [Ref 
7:p. 61] 

2. How Often the Information Should he Presented 

Management does not have the need, or is capable of, reviewing every 
report that is generated every day. There are certain areas of the operation that 
reqixires management’s attention on a daily basis, but there are other areas that 
require only occasional review. An automated management information system 
should help management in deciding what reports should be reviewed at any 
given time [Ref 8:p. 19]. Managerial reports fall into three report generation 
frequency categories; 1) routinely scheduled reports; 2) reports by exception; 3) 
reports provided upon request. Each are discussed below. 






a Routinely scheduled reports 

If the reports are for satisfying comfort information requirements, 
then the reports should be generated on a routine, periodic basis. An example of 
this type of report would be the Status of Fimds report that would be presented 
to the Commanding Officer on a weekly basis. 
h. Reports By Exception 

If the report is for providing warning information, then the report 
might be more appropriate on an exception basis. An example of this would be 
the monitoring of the use of overtime. If the planned overtime budget is 
exceeded by a certain percent, the report is automatically generated for the 
Comptrollers review. This form of exception reporting also works well with 
monitoring cost center optar balances and accoimts that have special restrictions, 
c. Reports Generated Upon Request 

Reports in this category would be trend analysis reports. These 
reports could be tailored to meet the planning information requirements for 
budget preparations, or "what-iT scenario’s. 

3. Automated Management Information System Reports 

The Comptroller’s AFMIS needs to meet the following information 
requirements: 

• Replicate the financial summary data that the mqjor claimant is reviewing. 

A Comptroller can not accurately respond to inquiries made by the nugor 
claimant involving the financial status of the command without being aware 
of what the nugor/sub claimant is reviewing. [Ref. 8:p. 19] 

• Generate summary charts for presentation to the Commanding Officer, 
Executive Officer, and department heads. These graphs should provide 
comfort and/or warning information. These charts/graphs should depict 
trends over a period of time as well as compare actual performance against 
the planned budget. 
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• Generate summary information graphs of high interest or sensitive areas. 
This woTild encompass financial accoimts with ceilings (a maximum imposed 
amount to be spent in a given area) or floors (accounts that are required to 
have a minimum amount of Amds expended in them). This would also 
include congressionally sensitive items such as interest payments and 
outstanding travel advances. 

• Generate summary charts for monitoring the internal operation of the 
Comptroller department. Management reports are needed to evaluate the 
performance and effectiveness of the employees/department as well as 
identifying weaknesses. 

The frequency and distribution of these various types of management 
graphs/reports would vary for each command. The following management 
information reports are considered to be the minimum reports for a shore 
activities AFMIS [Ref. l:p. D98, 6:pp. 9-10, 8:pp. 19-20]. 

CL Unddivered Orders Reports 

Undelivered Orders (UDO’s) represent capital tied up into goods 
or services not yet received [Ref. l:p. B241. There are a several reasons to 
monitor UDO’s. First, in the event of a funding shortfall, UDO’s could possibly 
be cancelled and the funds recouped. Second, an order may have been cancelled 
and the resulting funding credit not reflected in the IDA system, therefore a 
possible source of fimds. Finally, nngor/sub claimants monitor subordinate 
commands UDO’s. 

UDO’s should be monitored by both dollar value (Appendix A 
Figure 1) and by quantity (Appendix A Figure 2). A few high value UDO’s could 
inappropriately skew the charts. 

h. Unmatched Expenditures Reports 

Unmatched expenditures are discrepancies between the 
information in IDA, on an obligation document, and the billing documents 
information. These discrepancies arise due to data entry errors or prices 





changes/variances between the obligation document and the actual price charged 
on the billing document. 

Unmatched expenditures require the attention of a Comptroller 
for two reasons. First, with each unmatched expenditure there exists the 
possibility that the obligated amoimt in the IDA accoimting system is 
understated (the goods or services cost more then the posted amoimt), this could 
contribute to an over obligated status (violation of Title 31 section 1517). The 
reverse also holds true, in that, if there is a substantial amount of overstated 
obligations, then there are funds available in the system that a Comptroller is 
unaware of. 

Second, an effort on the part of the accounting staff is dedicated 
to resolving unmatched expenditures. Monitoring unmatched expenditures gives 
management a tool to review how well the staff is performing in respect to 
resolving unmatched expenditures. 

Unmatched expenditures should be tracked by both dollar value 
(Appendix A Figure 3) and quantity (Appendix A Figure 4). 
c Obligation and Commitment Reports 

A commitment is an administrative process of reserving funds for 
a future obligation. An obligation is an order placed or a contract awarded. An 
obligation is an official reservation of fimds. Both commitments and obligations 
directly affect the future balance of funds. It is necessary to monitor both 
obUgation and commitment level to ensure that a Title 31 violation is not 
incurred. The following five reports assists the Navy shore command’s 
management in monitoring commitments and obligations at various levels of the 
organization. [Ref. l;p. B15] 
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(1) Commitments Planned vs. Actual Report. Monitoring available 
funds (Total Obligated Authority less Gross Adjusted Obligations equals Available 
Balance) reqviires that both commitments and obligations be reviewed together. 
This will give management the information needed to evaluate the current 
funding environment within the command (Appendix A Figme 5). 

(2) Obligations Planned vs. Actual Report. Obhgations are the 
official reservation of funds based upon placing an order or awarding a contract. 
This report is reviewed by the mfgor claimant, via IDA, to evaluate an activity’s 
obligation rate compared to its budgeted rate (Appendix A Figure 6). 

(3) Base Operating Expense Report. Next to Civilian payroll 
expenses, base operating costs are traditionally the next highest expense 
category. The Base Operating Expense Report should be a summary report of all 
base operating expense accoxmts (Appendix A Figure 7). 

(4) Cost Center Operating Target Report. Commanding Officers 
allocate fimds to cost centers for the purpose of conducting their daily business. 
The Cost Center OPTAR Report serves as a routine management tool for the 
cost centers, and as an exception report to the Comptroller if the cost center 
exceeds the parameters imposed within the report (Appendix A Figure 8). 

(5) Reimbursable Execution Report. The majority of shore 
activities require the assistance of other commands/organizations to perform 
services. This is often done on a reimbiu-sable means. The requesting command 
submits a work/service request to the providing organization. Within this work 
request there is an agreed dollar amount that it will cost for the service. The 
amount of the work request is obligated upon submission to the servicing 
activity. Failure to monitor reimbursable accounts could lead to either an 
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account with excess fimds, or an over obligated account at the end of the fiscal 
year. 

The Reimbursable Execution Report (Appendix A Figure 9) monitors the 
actual reimbursable execution, compared to the planned. This report would be 
generated on an exception basis (the actual cost of the reimbursable work falls 
outside the parameters of the budgeted costs). 
d. Civilian Pay Reports 

The following four civilian personnel reports are recommended: 
Management to Payroll Planned vs. Actual, cvunulative; Management to Payroll 
Planned vs. Actual, by pay period; Overtime Dollars Pl ann ed vs. Actual; and Civil 
Service Grade Creep. [Ref. 8:p. 20] 

(1) Management to Payroll Reports. 

If a civilian pay accmmt becomes over obligated, corrective 
action can involve several different initiatives, depending upon the severity of the 
over obligation and how early the problem was identified. The solutions range 
from hiring freezes, laying off temporary employees, elimination of overtime, and 
possibly furlough. 

The civilian payroll accounts should be monitored, at a 
m i n i m u m , on an exception basis. The accounts should be monitored on both a 
cumulative (Appendix A Figure 10) and pay period basis (Appen ”'' A Figure 11). 

(2) Civilian Overtime Dollars Report. If civilian overtime dollars 
are budgeted out to the cost centers, then this report would be appropriate for 
review at the cost center level on a periodic basis (Appendix A Figure 12). If the 
overtime dollars are centrally managed, then the reports should be generated for 
the shore command’s management to review. 
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(3) Civilian Personnel Grade Creep Report. By monitoring the 
overall average civil service grades within the organization, it is possible to 
evaluate the hiring practices of the organization. The average civil service grade 
directly affects the overall cost within the civilian pay account. This report 
would be appropriate for review on a periodic basis (Appendix A Figure 13). 
e Higher Authority Interest Item Reports 

Due to Congressional interest in the Navy’s budgeting process, 
there are financial accoixnts that receive closer then normal scrutiny from the 
m^or/sub claimant. These high interest areas warrant incorporation into the 
AFMIS. Interest payments, as a result of not meeting the Prompt Pa5mient Act 
provisions, (Appendix A Figure 14) and Outstanding Travel Advances (Appendix A 
Figure 15) are examples of currently highly visible accounts. [Ref. l:p. D98] 

C. COMPATIBILITY OF FINANCIAL MANAGEMENT INFORMATION SYSTEMS 
Compatibility is a critical aspect of any automated information system. 

When an information system involves more then one computer system, the 
question of compatibility arises. Compatibility of computer systems have two 
areas of focus; compatibility of hardware (computers) and compatibility of 
software. 

Micro-computers are in use at both the cost center level and the 
comptroller department level. If an AFMIS system is going to encompass these 
two activity levels, then the hardware configuration must be compatible. A 
comptroller’s AFMIS should have the capability of receiving financial data from 
the cost centers (electronically) and the cost centers should be able to receive 
data from a comptroller’s AFMIS. Without hardware compatibility, the electronic 
transfer of data would not be possible. 
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RMS activity AFMIS’s sho\ild be compatible with the Navy’s official 
accounting system (IDA). An RMS activity AFMIS should have the capability to 
electronically receive (download information) and transmit (upload information) 
data between the two systems. Without compatibility, the information will have 
to be manually transferred from one ^stem to the other. 

As with hardware, software within a AFMIS must also be compatible. If 
information that is entered in one part of the AFMIS is intended to be used in 
another part of the AFMIS, then the different software components that share 
this data must be compatible (data must be stored and retrieved in a format that 
is recognizable by the two systems). Without direct compatibility, an additional 
program might be required to modify the format of the data from one program 
to the other program so that the data can be used. Or worst case, the data will 
not be transferable due to the lack of compatibility. 
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III. RMS ACTIVITY FINANCIAL MANAGEMENT INFORMATION SYSTEM’S 

A. OVERVIEW OF FINDINGS 

While conducting interviews at the RMS activities, the following 
observations were made: There is very little consistency between the comptroller 
departments AFMIS’s; There is no guidance available to the RMS activities as to 
how to approach the development of a APMIS; Of the five RMS activities that 
were reviewed, there is not a single application program that was utilized in 
more then one activity; The methodology as to how comptrollers generate their 
management reports are all different; and, the use of micro-computers varied 
considerably from each command. 

B. GUIDANCE ON THE DEVELOPMENT OF AUTOMATED FINANCIAL 
MANAGEMENT INFORMATION SYSTEM’S 

Based upon a literature search and the interviews conducted, it b the 
opinion of this author that there has been no guidance provided to RMS activity 
comptrollers for the purpose of automating a local FMIS. 

C. CURRENT IN-PLACE FINANCIAL MANAGEMENT INFORMATION 
SYSTEM’S AT RMS ACTIVITIES 

1. Features of In-place Automated Financial Management Information 
Ssrstem’s (AFMIS) 

The features of the various AFMIS’s vary greatly. There is very httle 
commonality amongst the Navy shore activities. The features of the different 
^sterns include: 
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• Electronic transfer of either accounting data or report information from IDA 
to the RMS activities AFMIS. Of the five RMS activities, one activity is 
downloading information (electronic transfer of data from IDA to the 
activities AFMIS). The other four RMS activities use IDA printouts to 
extract the relevant data for review. 

• Automated report generation. Automated report generation varies at the 
five commands. Four of the five commands use micro-computers to 
manipulate and display data. The one activity that does not use the micro¬ 
computer relies upon Tnamifll ledgers and the IDA printed reports. 

• Ability to generate reports by exception. None of the RMS activities use a 
report by exception reporting methodology. All reports are generated upon 
request. 

• Use of graphs and charts to display management reports. Two of the five 
RMS activities use graphical printouts to present their information. The 
other three activities present their information in spreadsheet format. 

• Data sharing among micro-computer users. Of the five systems reviewed, 
one RMS activity has the capability to share information with other users. 
All other systems are application and user independent. 

• Exportation of AFMIS to cost centers for use. One activity has exported 
their AFMIS out to their cost centers for use. 

• Ability to upload data to EDA from the local AFMIS. None of the RMS 
activities have this capability. Presently two of the activities are pursuing 
this capability (independent of each other). 

2. What Are The Similarities Of The Various Automated FMIS’s 

Presently there is no standardization among any of the reviewed 
activities for gathering, manipulating, and reviewing automated financial 
management information. This has resulted in very few similarities. In the 
absence of guidance, all reviewed activities are determining and creating their 
own versions of an automated FMIS. The degree of automation in the FMIS’s at 
the comptroller department level ranged from very little, to activities that use 
micro-computers on a routine basis for the purpose of information gathering and 
report generation. 
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All of the activities reviewed use the same basic financial information 
on a routine basis. But, there is no common method used for extracting the 
data and preparing it for presentation to management. 

The software used on the micro-computers in the Comptroller 
Departments are also different. Both In-house developed software, where the 
command’s computer programmers write a special designed program for that 
command (at one RMS activity), to the use of various Off-the-shelf software 
packages, such as Lotus 1-2-3 and dBase m, were used. For those activities that 
used the "off-the-shelT software, the accountants and budgeteers in the 
comptroller department developed their own applications (working versions of the 
program). 

3. How The Automated FMIS’s Were Developed 

While conducting the interviews, at the RMS activities, the following 
observation was: Comptroller Department personnel have very little, if any, 
xmderstanding as to how to go about developing an automated FMIS. The 
automated systems that are currently in-place are piece-meal. The development 
is piece-meal in that an employee sees a need and p\irsues the automation of 
that particular report for a given financial area. More often then not, other 
potential requirements that could also be met by these efforts are not taken into 
accormt. 

This approach to automating a FMIS results in several applications 
that possibly are redundant in nature, or, are not compatible with each other. 
Also, with this independent development effort, a problem arises as to who 
maintains the programs that were developed, and how will they be maintained. 
Modifications/changes to a program that are independently developed by a user 
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are very difClciilt and costly. Individuals that develop a program for their own 
use in an office environment traditionally do not document how the program 
operates. The user develops the program while they are working at their desk, 
and once the program meets their needs, they start using it without th inkin g of 
documenting what they have done. This was the case at the five RMS activities 
reviewed. 

4. Problems Encountered in the Development of AFMIS’s 

During the development of the AP’MIS’s at the activities reviewed, 
several problems were encountered. The following "lessons learned" were 
vocalized during the interview process: 

• The developers failed to identify what computer systems were available to 
the users. The developed application ended up not being compatible in all 
cost centers, which required the cost centers to procure additional 
equipment. 

• Users where not involved in the development process. This lack of 
involvement resulted in fiawed reqiiirement specifications. 

• The developed application required the cost centers to have a copy of a 
particular software package to use the AFMIS. Several cost centers did not 
have the required software package, and, did not have the funding to 
procure the required package. 

• The developers of the application assumed that the users were familiar with 
computers and the selected "Off-the-ShelT software. This lead to the 
development of an application that was too complex for the average user to 
use. 

• Failure to field test the system prior to full implementation resulted in an 
unreliable product that users refused to use. 

• Lack of scheduling formal training resulted in the implementation of the 
AFMIS with little support from the users. It was assinned that the users 
would be interested enough in the new AFMIS to obtain the training 
required for the new system, on their own. 

• Desk top guides were not developed for the users. This greatly hindered 
the implementation process and user acceptance. 






• Backup and recovery procedures where not adeqixately tested prior to 
implementation. This resulted in a cost center having to re-enter a 
significant amount of data into the AFMIS. 

• Use of the developed AFMIS at the cost centers was not mandatory. 
Therefore, the cost centers refused to convert over from their old/familiar, 
system to the new system. 

• There was no docrunentation for the AFMIS. When the developer 
transferred, there was no one knowledgeable within the organization to 
maintain the software. 

5. Compatibility of AFMIS's 

Compatibility of in-place AFMIS’ were reviewed from three 

prospectives. First, from the view point of compatibUity within the Comptroller 

department. Second, the compatibility between different RMS activities. And 

third, the compatibility between the RMS activities AFMIS and EDA. 

a. Compatibility within the Comptroller Department 

The computer hardware within the reviewed activities where 

foxmd to be compatible. And, the software in \ise (primarily Lotus 1-2-3 and 

Dbase m) by the RMS activities were also found to be compatible, in that the 

programs are able to retrieve and store data in a format that can be recognized 

between the programs. 

However, the compatibility of the applications (application being 
the adaptation of the commercial software to meet their needs) that are in use, 
are developed with little, if no consideration of other potential, or currently 
existing, applications. As a result, the applications are not compatible with each 
other. The applications are not able to share or transfer data electronically to 
other applications. 





6. Compatibility Between RMS Actioity AFMIS*s 

There is no apparent need for compatibility between RMS activity 
AFMIS’s. RMS activities do not share any financial data between them. 
Therefore the need for compatibility does not exist. 

c Compatibility Between RMS Activity AFMIS's and FIPC 

The determination of compatibility between RMS activity AFMIS’s 
and FIPC is beyond the scope of this thesis. There is a need for the 
compatibility between FIPC and the RMS activities. Presently, there exists the 
capability for FIPC’s to download data to RMS activities. Presently none of the 
reviewed RMS activities have the capability to upload to the FIPC system. Two 
of the five RMS activities are in the process of trying to gain this capability. 
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IV. CONCLUSIONS 


A. INTRODUCTION 

The conclusions offered in this chapter are based upon the readings, 
interviews, and observations made during the research conducted in the coiu^ of 
this thesis. 

B. CONCLUSIONS 

For RMS activities to be able to effectively manage their financial 
resoxirces, it is necessary for the activity to have a local financial management 
information system (manual or automated) to supplement IDA reporting 
capability. Without exception, the reviewed activities recognize the importance of 
a local financial management information ^stem and have one in place. 

The IDA accounting system is not setup to provide the required up-to-date 
information in the format that the RMS activity managers require. The 
consensus among the RMS activities is that IDA’s cmrent report generation 
capability is inflexible and difficult to interpret. 

Throughout the discussions with comptroller department personnel it is 
recognized that micro-computers can help them in their daily routine but are at 
a loss as to how to go about it. RMS activities need to take greater advantage of 
their available micro-computers. Micro-computers can enhance the productivity 
of the comptroller’s department greatly. Computers take about 20 percent of the 
manpower time that manual calculations do [Ref. 9;p. 65]. 

With the RMS activity Comptrollers recognizing the need for automated 
financial information 9)rstems, the Comptrollers have been encouraging their 





accoiintants and budgeteers to automate applications within their functional 
areas. The problem with this approach is that the staff does not have an 
adequate understanding as to how to approach the development of an AFMIS. 

The applications that are developed are stand alone applications with very little 
consideration of other possible applications. 

C. RECOMMENDATIONS 

RMS activities have two basic, but common, features. First, the information 
requirements at RMS activities are similar. Second, with micro-computers being 
readily available at the RMS activities, the focus of an AFMIS should be towards 
taking advantage of theses computers. The two recommendations made, take 
into account that IDA will adventually be replaced by a DoD standard accoimting 
^stem. 

These recommendations can be accomplished through the Navy 
Postgraduate School (NPS) Thesis process. If the NPS is used to accomplish 
these recommendations, it should be sponsored by the appropriate organization 
level that is able to promote and distribute the final product. 

1. Development of a Generic Automated Financial Management 
Information System 

To minim ize the ciurent duplication of effort in developing AFMIS’s at 
the local activity level, a generic AFMIS should be developed. With the majority 
of the information requirements being the same at all shore activities, a generic 
AFMIS could be developed to support these common needs. The following 
featxires should be considered during the development of the generic AFMIS. 

• The use of "Oflf-the ShelT software in this development effort could greatly 

reduce the development time and effort. 






• The generic AFMIS should be developed with modularity in mind. The 
shore activity should not be required to implement the complete AFMIS to 
take advantage of particiilar features of the AFMIS that the activity is 
interested in. 

• The generic AFMIS should include a report generation capability so that 
the individual activities can customize their reports to meet their needs. 

• The generic AFMIS should include a recommended training plan for 
activities to follow. Recommend the incorporation of an on-line tutorial (a 
computer program for training new users) as part of the training package. 

• The generic AFMIS needs to be accompanied with a users guide for each 
type of intended user. Documentation on the application is necessary so 
that modification of the system at the local level would be possible. 


2. Establish Guidance for RMS Activities to Develop an AFMIS 

Presently there is no published guidance as to how to automate a 
finan cial mformation system at RMS activities. Without having a guide to help 
direct the efforts of the shore activity, the difficulties encountered by various 
activities, as indicated in the findings, will reoccur at other activities. 

Without guidance, systems will continue to be developed that are not 
standardized with other Navy activities. Even though the activities do not share 
financial data between them, reassignment of employees, via transfers, are 
common. With non-standardized AFMIS’s, the need for the activity to retrain 
the newly arrived employee from another Navy activity, is an expense that could 
be prevented. 
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APPENDIX A - SAMPLE MANAGEMENT INFORMATION REPORTS 
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Figure 2 Undelivered Orders by Quantity 











Figure 3 Unmatched Expenditure by Dollar Value 










Figure 4 Unmatched Expenditures by Quantity 
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Figure 9 Reimbursable Report 
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Management to Payroll 



Figure 10 Management to Payroll, Cumulative 
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- Report by Exception 
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Figtire 15 Outstanding Travel Advances Report 
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APPENDIX B • PRACTICAL COMPTROLLERSHIP COURSE AND FINANCIAL 
MANAGEMENT OF THE ARMED FORCES STUDENT TEXTBOOK SUPPLEMENT; 
AUTOMATION OF A FINANCIAL MANAGEMENT INFORMATION SYSTEM 


Based upon comments from students attending the Practical 
Comptrollership Course at the Navy Postgraduate School it was apparent that 
there were many misconceptions as to what an automated financial management 
information system (AFMIS) is, what it should be, and how to develop one. This 
paper is based upon a review of several Navy shore activities and their Financial 
Management Information Systems (FMIS). 

This paper first addresses what management information is, then what a 
AFMIS should provide with respect to management information. The final 
chapter discusses how to approach the development of an AFMIS. 

There are four appendixes to this paper. Appendix AA, is a proposed 
check-off list that a command covdd use during the initial phases of developing 
an AFMIS. The check-off list is designed to assist an organization in starting off 
in the right direction of initiating the development effort within their command. 

Appendix BB is a listing of lesson’s learned by various shore activities that 
implemented an AFMIS. Appendix CC contains sample management information 
reports that an AFMIS should provide. 
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Appendix DD is a general discussion on what a computer is and how it 
works. It is oriented towards those that have very little experience or knowledge 


as to how computers operate. Appendix DD is not intended to serve as an 
extensive guide on computers, there are various books on the market addressing 
this particular topic. 
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I. MANAGEMENT INFORMATION 


A- MANAGEMENT INFORMATION SYSTEMS 

There is a difference between a Management Information System (MIS) and 
an Automated Management Information System (AMIS). MIS is any standardized 
approach to accumxilating data and adjusting/manipulating the data in a manner 
that is useful to an organization. This includes: personnel files; pa5n:oll records; 
financial status of the organization; work schedules; etc. 

An Automated MIS (AMIS) is a computerized system that accepts input 
from various sources and manipulates the data to generate useful information for 
management. Depending upon the size of a requirement, an automated system 
could be operated on a computer as small as a micro-computer (desk top 
computer) or as large as a mainframe computer at a computer center. 

B. COMPTROLLER MANAGEMENT INFORMATION REQUIREMENTS 

When trying to identify what management information is required to 
support a comptroller, three questions need to be answered: 1) What 
information needs to be reported to the Commanding Officer, Executive Officer, 
Department Heads, and the Comptroller, so that they can effectively execute the 
responsibilities of their offices. 2) How should the information be presented. 
The method of presentation can directly affect how they will interpret the 
information, and the amount of effort required by management in reviewing the 
information. 3) How often should the information be presented? Should 
management review every report on a weekly basis? Or, should they review only 
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selected reports on a periodic basis. Should exception reporting be used? The 
latter two questions are addressed first, followed by what is considered the 
miniTniiTn management information that is required in an AFMIS. 

1. How the Information Should be Presented 

Management is required to be aware of the status of a multitude of 
financial accovmts, appropriations, and special interest items. They must be able 
to review these varioxis areas in the most efficient manner possible. The trend 
in the commercial sector has been towards the utilization of graphical 
presentations in management information systems. In 1986, sixty-seven percent 
of all reviewed MIS’s used computer graphics. Graphics, if presented properly, 
have the ability to depict trends more clearly to management, compared to the 
same information that is displayed in a column format in a report. [Ref. 7:p. 61] 

2. How Often the Information Should be Presented 

Management’s time is a precious resource, therefore, we want to focus 
their available time on the most relevant information within the organization. 
Management does not have the need, or is capable of, reviewing every report 
that is generated every day. There are certain areas of the operation that 
requires management’s attention on a daily basis, but there are other areas that 
require only occasional review to ensure that things are on track. A 
management information system should help management in deciding what does 
and does not require their attention. [Ref. 8:p. 19] 

Managerial reports fall into three report generation frequency 
categories: 1) routinely scheduled reports; 2) reports by exception; 3) reports 
provided upon request. Each are discussed below. 





a. Routinely scheduled reports 

If the reports are for providing comfort information then the 
reports should be generated on a routine, periodic basis. An example of this 
t 3 T)e of report would be the Status of Funds report that would be presented to 
the Commanding Officer on a weekly basis. 
h. Report By Exertion 

If the report is for highlighting potential problems, then the 
report might be more appropriate on an exception basis. An example of this 
would be the monitoring of the use of overtime. If the planned overtime budget 
is exceeded by a certain percent, the report is automatically generated for 
managements review. This form of exception reporting also works well with 
monitoring the cost center optar balances and accounts that have special 
restrictions. 

c. Reports Generated Upon Request 

The type of reports that could be in this category are trend 
analysis reports. These reports could be tailored to meet the planning 
information requirements for budget preparations, or "what-iT scenario’s. 

3. Automated Management Information System Reports 

The Comptroller’s AFMIS needs to meet the following information 
requirements [Ref 8:p. 19]: 

• Replicate the financial summary data that the mqjor/sub claimant is 
reviewing. 

• Generate summary charts for presentation to the Commanding Officer, 
Executive Officer, and department heads. These graphs will provide 
comfort and/or warning information. 
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• Generate summary information graphs of high interest or sensitive areas. 

• Generate summary charts for monitoring the internal operation of the 
Comptroller department. 

The frequency and distribution of these various types of management 
graphs/reports would vary for each command. The following management 
information reports are considered to be the minimum reports of an AFMIS [Ref. 
l:p. D98, 6:pp. 9-10, 8:pp. 19-20]. 

• Undelivered Orders Reports (Appendix CC Figures 1 and 2) 

• Unmatched Expenditures Reports (Appendix CC Figures 3 and 4) 

• Obligation and Commitment Report (Appendix CC Figure 5) 

• Obligations Planned vs. Actual Report (Appendix CC Figure 6) 

• Base Operating Expense Report (Appendix CC Figure 7) 

• Cost Center Operating Target Report (Appendix C Figvire 8) 

• Reimbursable Execution Report (Appendix CC Figure 9) 

• Management to Payroll Reports (Appendix CC Figvu-es 10 and 11) 

• Civilian Overtime Dollars Report (Appendix CC Figure 12) 

• Civilian Personnel Grade Creep Report (Appendix CC Figure 13) 

• Interest Payments Report (Appendix CC Figure 14) 

• Outstanding Travel Advance (Appendix CC Figure 15) 

C. COMPATIBILITY OF FINANCIAL MANAGEMENT INFORMATION SYSTEMS 
Compatibility is a critical aspect of any automated information system. 

When an information system involves more then one computer system, the 
question of compatibility arises. Compatibility of computer systems have two 







areas of focus; compatibility of hardware (computers) and compatibility of 
software. 

Micro-computers are in use at both the cost center level and the 
comptroller department level. If an AFMIS system is going to encompass these 
two levels of the organization then the hardware configmation must be 
compatible, otherwise the sharing of programs and data would not be easily 
accomplished. Hardware compatibility is also an issue between a Comptroller’s 
AFMIS and the IDA system. 

As with hardware, software within an AFMIS must also be compatible. If 
information that is entered in one part of the AFMIS is intended to be used in 
another part of the AFMIS, then the different software components that share 
this data must be compatible (data must be stored and retrieved in a format that 
is recognizable by the two systems). With out direct compatibility, an additional 
program might be required to modify the format of the data from one program 
to another so that the data can be used. Or worst case, the data will not be 
transferable due to lack of compatibility. 

An organization’s AFMIS ideally should be compatible with the FIPC’s 
official accoimting syst "ru An AFMIS should have the capabihty to electronically 
receive (download information) and transmit (upload information) data between 
the two systems. An AFMIS should also be compatible between a comptroller’s 
and cost center’s AFMIS. A comptroller’s AFMIS should have the capability of 
receiving, electronically, financial data from the cost centers and the cost centers 
shoiild be able to receive data from the comptroller’s AFMIS. 
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II. HOW TO DEVELOP AN AFMIS 


A. DISCUSSION 

The effort involved in developing an AFMIS ia often underestimated by 
both management and users. The investment of both time and money needs to 
be recognized up front, prior to undertaking the effort of automating a FMIS. 
Without properly recognizing this, it will be difficijlt for management to 
adequately support the project. Management’s commitment to the development 
effort and cost incurred throughout the development period often determines the 
level of success as to quality of the completed ^stem [Ref. 10:pp. 263-264]. 

1. Development Methodologies 

There are several industry accepted methodologies as to how to 
approach the development of an automated information system. A methodology 
is a framework for guiding a software development project from conception to 
completion. The methodologies fall into two basic categories: System 
Development Life Cycle; and Protot 3 q)ing. [Ref. 5:pp. 603] 

The System Development Life Cycle (SDLC) approach is a traditional 
methodology that has been extensively used over the years. SDLC is a specific 
step by step process for developing the system. A distinctive feature of this 
approach is that once the developer identifies the requirements that the user 
thinks he/she wants, the software development team goes forward with the 
development of the application. The user’s involvement with the SDLC 
methodology is limited to the initial requirements phase and the acceptance of 
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the product. It is not imtil the latter part of the development effort that the 
user gets to actually see what the end product is going to look like. If the user 
finds out at this point that they didn’t correctly identify all of the requirements 
that they wanted in the system, it is often too late, or too costly, to change. 

The Prototyping methodology, in contrast, asstunes that the user is not able to 
accurately identify the requirements of the ^stem up front. Prototyping is an 
approach that keeps the user involved throughout the development process. 

This approach requires both the user and the developer to sit down and review 
what the user hkes and dislikes with the current ^stem in place. From this the 
developer creates a working model (prototype) that emulates what the developer 
thinks the user wants. The user reviews the prototype and tells the developer 
what he/she likes and dislikes about the system. Based upon this review the 
developer modifies or creates a new protot 3 rpe for the user to review. This 
process continues until the user is satisfied with the presented prototype. With 
this information, the developer can now go forward and develop the working 
system, now knowing what features are desired in the system. [Ref. 5:pp. 603- 
613] 

2. Determining System Requirements 

A manager’s ability to make quality decisions is directly related to the 
quality and availability of information that pertains to the issue at hand. 

Without having the right information at the right time, a manager is unable to 
carry out his/her responsibilities effectively. This identifies two general 
attributes of information. The information must be "the" information that the 
manager needs for the particular decision making process that he/she is 
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encoimtering. And, the information mtist be timely. Timeliness is crucial, 
receiving the infomaation v/hen there is not adequate time for the manager to 
take advantage of a situation, or to correct a problem is unacceptable. 

All managers have different ideas as to what information is needed, 
and when the information is needed, in any given situation. The variances stem 
from some managers having a better feel for a particular situation, or maybe 
having a better understanding as to what information is most relevant. Also the 
level of experience of the manager will impact the managers information 
requirements. Depending on the level of diversity in the organization and the 
dynamics of the business routine, information requirements could range from a 
very stable (a very systematic and well established routine), to a very d 3 niamic 
organization that has continually changing information requirements. 

A key element in obtaining the 83 rstem that the user needs is knowing 
what the user wants in the system. Management knows that they need 
information to be able to accomplish their jobs, but the ability of managers to 
clearly state what information they need on a routine, periodic, or on a ad-hoc 
basis, is often very difficult [Ref ll:pp. 98-99]. Without clearly identifying what 
is expected out of an AFMIS prior to the development of the ^stem, it is 
unlikely that the ^stem being developed will meet the needs of the organization. 

Critical Success Factors (CSF) is one approach that can assist the 
development team in determining the users requirements. CSF’s are important 
functions within the organization that must achieve a minimum standard to be 
considered successful. CSF’s are derived through a series of interviews, focusing 
on what is necessary for the interviewee to be successful within their position. 
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By determining what the CSF’s are, it is possible to determine the information 
requirements for supporting those CSF’s. [Ref. 12:pp. 6-8] 

Utilizing only the CSF’s is not enough for the purpose of identifying 
all of the requirements of an AFMIS. The utilization of questionnaires for 
management to respond to, will provide an addition means of evaluating the 
information needs of management. The questionnaire will provide for a standard 
means of comparison between managers to evaluate the overall needs of the 
organization. [Ref. 4:p. 115] 

Another source for determining information needs is by collecting all 
currently prepared reports within the organization. This should include both 
currently automated reports and manually prepared reports. 

3. Prioritization of Information Requirements 

Once all of the requirements are identified for the proposed new 
system, it is important to place priorities on all of these requirements. The 
importance of this is that it might not be economically, or technically feasible to 
accomplish all of the fvmctionality of the requested system. Without a priority 
listing, approved by management, the development team may incorrectly choose 
which application to develop and which ones not to develop. 

4. Taking Inventory of Existing Hardware and Software Systems 
Determining the hardware systems that are currently within the 

organization will influence the development of the system. With an inventory of 
the existing computer systems, the developers will be able to determine if the 
existing hardware can be utilized with the new system or if the existing 
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hardware will need to be replaced. The compatibility of hardware systems is also 
an important concern during the development process. 

Taking inventory of the existing software applications within the 
organizations is important for two reasons. First, if there are applications 
currently in place that will be replaced by the new ^stem, there will be a 
requirement for converting the ciirrent ^rstem and information over to the new 
^tem. Second, some of the current applications might be usable in the new 
^stem. Reusability of current applications could reduce both the development 
time and cost. 

5. Evaluating the Feasibility of the Proposed System 

Throughout the development process, it is important to incorporate 
feasibility check points to ensure that the project is both feasible and affordable. 
With any system development project, the initial estimates are often inaccurate. 
As the development of the system progresses, better estimates can be made. 

The development team should be required to provide the requesting activity with 
the projected estimates of the project on a periodic basis. 

With each feasibility report, the requesting command should closely 
review the revised estimates. The activity may find that the project is becoming 
to costly, based upon how it is currently proposed. Decisions of reduction of 
scope or even cancellation of costly projects should be viable alternatives within 
the decision makin g process. 

6. Use of *Ofr*the*Shelf Software” vs. In-house Development 

In-house developed software is software that is specifically developed 

for a given ^stem. In-house development requires the full development 
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approach which includes: determining the users requirements of the system; 
deter minin g the logical design of the system (determining the specifications of 
the requirements); programmers writing the programs for the system; program 
testing; implementation of the system; and maintenance of the system. In- 
house development can be performed by the local commands computer 
specialists, a Navy Regional Data Automation Center (NARDAC), or a commercial 
contractor. This is traditionally a very lengthy and expensive process. 

An alternative to In-House development is "Off-the Shelf (OTS). 

There is a multitude of OTS software products in the commercial market. If 
possible, the use of an OTS application can possibly reduce the time and expense 
of a project. With the vast number of available OTS applications in the 
commercial market, it is Ukely that there are OTS applications that, with some 
minor modifications, could meet the needs of the system that is being developed. 
To use OTS, it is still necessary to go through the requirements phase of the 
development process. With out doing this, it would not be possible to adequately 
determine which OTS could meet the requirements. 

B. RECOMMENDED FRAMEWORK OF AN AFMIS 

An AFMIS, ideally, should encompass all three levels of the financial 
accoxmting system. That is, the system should be an integrated application that 
links the cost centers with the Comptroller department, and the comptroller 
department with the FIPC ^tem. The framework that is recommended here is 
a generic framework that can serve as a tool for activities to conceptiialize an 


55 










AFMIS. Figure 1 illustrates the Integrated AFMIS Framework. The framework 
is briefly discussed here at both the comptroller level and the cost center level. 

1. Cost Center AFMIS 

a. Entry of Obligations 

Ideally an AFMIS should promote the philosophy of "one time 
data entry". That is, data should only have to be entered into the AFMIS once. 
All other fvmctions that need to utilize that data should be able to have access to 
it via the AFMIS. 

The concept of one time data entry should be introduced at the 
cost center level. The cost centers are the origination points for initiating 
obligations. Since cost centers need to keep track of their obligations in their 
local accormting system (cost center memorandum records), the entry of the 
obligation into their AFMIS should also serve as the data entry into IDA (after 
review by the Comptroller’s accoimtants). 

If properly developed, the AFMIS (at the cost center level) can 
have detailed error checking routines for validating the information that is being 
entered. By validating the data at the cost center level, data entry errors can be 
reduced. If errors are encoimtered, the user can correct the discrepancy at the 
terminal. 
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GENERIC AFMIS FRAMEWORK 



Figure 1 Generic AFMIS Framework 
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b. Transaction Listings 

Transaction Listings (TL) should be automatically forwarded to the 
cost center AFMIS via electronic means from the Comptroller’s AFMIS. 

The cost center’s AFMIS can be developed to automatically 
compare the TL’s with the information contained in the local AFMIS. The 
AFMIS should be able to assist in the reconciliation of the TL’s, and generate a 
hard copy listing of those TL’s that require further action. 

Once the TL’s are reconciled, the AFMIS should pass the 
corrections to the Comptroller’s AFMIS for review and approval for updating the 
IDA system. 

c. Cost Center Report Generation 

The local AFMIS shovdd be able to generate management 
information reports for the cost center’s management. These reports should be 
able to be tailored to the particular needs of the cost center. 

2. Comptroller AFMIS 

a Entry of Obligations 

With obligations being entered at the cost center level, the 
Comptroller’s accountants will serve as a review point for these obligations. The 
accoxmtants will receive the obligations via the AFMIS. The obligations will be 
reviewed on the monitors by the accountants and if no discrepancies are noted, 
the obligations are forwarded onto the IDA system. If discrepancies are 
identified, the obligation is rejected and sent back to the cost center for 
correction, via the AFMIS. 
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Two accounting functions are taking place upon completion of the 
review of the obligations by the accountants: First, the activities memorandiim 
records are being updated; Second, the IDA system is being updated. 
b. Transaction Listings 

Transaction Listings should be electronically received from the 
FIPC system. Upon receipt of the TL, the Comptroller’s AFMIS should sort the 
TL into cost center sequence. The sorted TL is then forward to the cost centers 
for corrective action. 

Once the cost centers have reconciled the TLs, the Comptroller’s 
accountants will review the corrections via the AFMIS. If no discrepancies are 
identified, the corrections are transmitted to the IDA system for update. 

CL Management Information Reports 

The report generation capability should be flexible so that it can 
be adapted to meet managements needs. Also, with the Comptroller’s AFMIS 
monitoring the daily transactions at both the activity level and the cost center 
level, the AFMIS should be able to generate exception reports when the 
conditions warrant it. 
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APPENDIX AA - CHECK-OFF LIST FOR AUTOMATING A FINANCIAL 
MANAGEMENT INFORMATION SYSTEM 

A. SOLICITING SUPPORT FROM TOP MANAGEMENT 

_ Review command procedures for requesting the development of an 

automated information system. The local Data Processing Center will have 
guidelines for the proper submission of requests. 

_ Obtain Command support for determining requirements of proposed 

system and conducting a feasibility study. 

B. DETERMINING REQUIREMENTS OF SYSTEM 
1. Copies of Current Reports 

_ Obtain copies of all current financial reports (both automated and 

manxial) used in the Accounting Division 

_ Obtain copies of all current financial reports (both automated and 

manual) used in the Budgeting Division 

_ Obtain copies of all current financial reports (both automated and 

manual) used by the Comptroller 

_ Obtain copies of all current financial reports (both automated and 

manual) presented to the Commanding Officer, Executive Officer, and 
Department Heads. 

_ Obtain copies of aU current financial reports (both automated and 

manual) generated for submission to higher authority. 
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2. Input From Users as to the Desired Capabilities of the Proposed 
System 

_ Determine the Critical Success Factors for each position affected by the 

system. Critical Success Factors is just one of many different methodologies to 
obtain what the bare minimum requirements would be from the users 
prospective. 

_ Use a questionnaire to solicit desired user requirements. The 

questionnaire format should be in a manner that will lend itself for comparison 
with each other once retvirned from the user. 

_ Consolidate all user identified requirements, then have the users 

determine the priorities of the requirements that they requested. 

C. TAKE INVENTORY OF EXISTING SYSTEMS 

_ Take a detailed inventory of all computer hardware ciurently in-place 

(computers, printers, modems, monitors, etc.). The inventory should depict type 
of equipment, quantity, and location. 

_ Take a detailed inventory of current applications in use. The inventory 

should include type of application, location, frequency of use, who the users are, 
and the intended use of application. 

D. INITIAL FEASIBILITY REPORT 

_ Does the feasibility report address compatibility of the proposed system 

between the Comptroller Department and the Cost Centers? 


61 








_ Does the feasibility report address compatibility of the proposed system 

between the Comptroller Department and IDA? 

_ Does the feasibility report address the cost of additional hardware 

requirements? 

_ Does the feasibility report address alternative approaches to the proposed 

system? 

_ Does the feasibility report address the development methodology? Will 

the development approach be Protot 3 q)ing or System Development Life Cycle? 
Prototyping is highly recommended, due to the greater involvement of the user 
throughout the development process. 

_ Does the feasibility study report the level of user involvement during the 

project? 

_ Does the feasibility report address the anticipated conversion costs 

involved? These costs would include transferring over any data in the current 
system over to the new system and training the users on the new system. 

_ Does the feasibility report address what the anticipated maintenance cost 

will be once the S 3 ^tem is completed? 

_ Does the report address the possibility of utilizing "Off-the-ShelT 

software? 

_ Does the feasibility report address the possibility of using existing 

applications within the proposed system? 

_ Does the feasibility report address the possibility of incremental 

development? Can the ^stem be developed by fimctional area and implemented 
once those areas are complete. New versions/releases of the application would 
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expand the capability of the system. This approach lends itself to organizations 
that do not have adequate funding for the entire project, but as money becomes 
available, additional modules can be developed and implemented. 

E. DETERMINATION AS TO CONTINUE WITH THE PROJECT 

_ Determine if the cost of the project warrants the continuation of the 

development effort. 

_ Determine if the development time frame is acceptable. If there are 

significant changes in the future for how the organization will be required to 
manage their financial operation, then is it worth the cost and effort to develop 
the proposed system? 

_ Are all requirements, identified by the users, going to be met? Are any 

of the requirements, determined by the development team, infeasible? If so, 
without these requirements is the system still worth the effort and cost? 
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APPENDIX BB • LESSONS LEARNED 
The following lesson’s learned are from Navy shore activities that have 
implemented AFMIS’s. This Ust is provided so that it may assist an organization 
in their development effort of an AFMIS. 

• Potential users were not correctly identified, this resulted in the application 
not meeting all of the user’s requirements. 

• The developers failed to identify what computer ^sterns were available to 
the users. The developed application ended up not being compatible in all 
cost centers, which required the cost centers to procure additional 
equipment. 

• Users where not involved in the development process. This lack of 
involvement resvilted in flawed requirement specifications, 

• Developers and users vocabulary are different. This resulted in 
misinterpreted requirements. 

• The developed application required the cost centers to have a copy of a 
particular software package to use the AFMIS. Several cost centers did not 
have the required software package, and, did not have the funding to 
procure the required package. 

• The developers of the application assumed that the users were familiar with 
computers and the selected "Off-the-ShelT software. This lead to the 
development of an application that was too complex for the average user to 
use. 

• Diuing the programming of the application, the information that is used to 
validate the users input (for error checking) was programmed as part of the 
program’s code in the software package. Without using look-up tables 
within the program (which is easier to modify) a new fiscal year required 
extensive reprogramming before the application could be used. 

• Failure to field test the system prior to full implementation resulted in an 
unreliable product that users refiised to use. 

• The lack of scheduling formal training resulted in the implementation of 
the AFMIS with little support from the users. It was assiuned that the 
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users would be interested enough in the new AFMIS to obtain, on their 
own, the training needed for the new system. 

• Desk guides were not developed for users. This greatly hindered the 
implementation process and user acceptance. 

• If an AFMIS is developed that has a high user acceptance, enhancements to 
the system must be planned and scheduled. It is very easy to continue to 
enhance an existing system, but this prevents the development of others 
applications that are competing for the same development resources. 

• The development approach failed to keep the users involved through out 
the development process. This resulted in a loss of interest by the users, 
which made acceptance of the system, once implemented, more difficult. 

• Use of the developed AFMIS at the cost centers was not mandatoiy. 
Therefore the cost centers refused to convert over from their old/familiar 
system to the new system. 

• There was no documentation for the AFMIS. When the developer 
transferred, there was no one knowledgeable within the organization to 
maintain or update the software. 

• Backup and recovery procedures where not adequately tested prior to 
implementation. This resulted in a cost center having to re-enter a 
significant amount of data into the AFMIS. 
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APPENDIX CC - SAMPLE MANAGEMENT INFORMATION REPORTS 
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Figure 4 Unmatched Expenditures by Quantity 
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Figure 8 Cost Center’s Operating Target Report 
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Figure 9 Reimbursable Report 
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Figure 10 Management to Payroll, Cumulative 
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Figure 13 Civilian Personnel Grade Creep Report 
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APPENDIX DD - COMPUTERS 


As micro-computers are readily available in most organizations, the 
emphasis in this document is on the use of micro-computers, also known as desk¬ 
top computers or personal computers (PC’s). Even though this paper addresses 
micro-computers, the theoiy is the same for all computer ^sterns, the difference 
will be in the size of the computer, cost of the computer, and the amount of 
information that can be processed in a given period of time. 

A computer is a tool. If understood and used properly, a computer can 
assist in conducting a multitude of repetitive tasks in a very fast and efficient 
mann er, A computer is an electronic device that follows very expUcit 
instructions. 

Since a computer is an electronic piece of hardware, a computer does not 
have the ability to think or mak e decisions on its own. A computer can only 
differentiate the difference between electrical voltage levels in circuits. And 
based upon these voltage levels, the computer can translate these into 
understandable instructions. The different voltage levels in the computer 
represents I’s and O’s. With the proper combination of I’s and O’s, the 
computer is able to imderstand and perform a fimction for the operator of the 
computer. (The term ’operator’ is a general term that identifies the person that 
is operating the computer. The term ’user’ in respect to micro-computers is also 
the operator.) Each possible 1 or 0 is called a bit. A combination of eight I’s or 
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O’s is called a Byte. A group of I’s and O’s that perform a function within the 
computer is call a computer instruction. It usually takes more then one byte to 
make up an instruction. And it takes thousands to millions of instructions to 
naake up a program, depending on the size of the application. 

There are several components to a computer system that must interface to 
provide the service that the users are asking of the computer. The overall 
pictvure of these components are shown in Figure # 1. Each component will be 
described so that the reader will have a general understanding of how a 
computer works. First the heart of the computer, which is called the Central 
Processing Unit, will be discussed. This will be followed with a discussion of the 
other four components. 

1. Central Processing Unit (CPU) 

The Central Processing Unit (commonly referred to as the CPU) is the 
heart of the computer. The CPU is the component that evaluates and executes 
the instructions of a program. The CPU is designed to interpret the series of I’s 
and O’s and based upon the evaluation, it will perform some action. This action 
could be one of a thousand different things, such as add a munber; subtract a 
number; request a new instruction; etc.. The key here is that the CPU is where 
all of the instructions are processed. 

All CPU’s are not the same. There are several different manufacturers 
that have designed and marketed their CPU. Since the CPU is the heart of the 
system, computers are designed around the CPU. 'This is so that the computer 
can take fvdl advantage of the capabilities of the of the CPU. Fortimately, in the 
SO’s, the Navy’s procmement practices resulted in a standard in micro-computers 
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Figvire 1 Components of a computer system. 


in the Department of the Navy QDoN). The mfyority of all micro-con’-,, aters 
purchased in the Navy were and still are IBM compatible. This mea..s that the 
micro-computers that are being purchased have a Central Processing Unit that 
executes IBM compatible software (software that operates imder the IBM Disk 
Operating System (IBM-DOS) or under the Microsoft Disk Operating System 
(MS-DOS), which are discussed later in this chapter). 

Due to the Navy’s purchasing practices, there are three CPU’s that 
will be encoimtered Navy activities. All three are manufactured by the Intel 
















Corporation. The CPU’s are labeled Intel 8086, Intel 80286, and Intel 80386 
(Intel is currently developing the Intel 80486, which will not be discussed here). 

a. Intel's 8086 CPU (PC, PC/XT) 

The processor used in the IBM-PC, in the early 80’s, was the 
Intel 8086. Compared to today’s standards, this is considered a slow processor 
for desk top applications. The IBM-PC (PC, stands for IBM-PC or compatible) 
was limited in its ability to expand (not because of the CPU but because of the 
design of the computer around the CPU). As a result, IBM redesigned the PC 
and came out with the IBM-PC/XT (XT, stands for IBM-PC/XT or compatible). 
The XT used the same CPU as the PC, but it had the flexibility to add 
additional peripherals (peripherals are hardware components such as disk drives, 
modems, mouse, etc., which will be discussed later in this chapter). 

b. Intel's 80286 CPU (AT) 

In the mid 80’s Intel released the 80286 CPU. This processor, 
along with the improved computer architectme designed aroimd it, was 
significantly faster then the 8086. This new computer was classified as the IBM- 
AT (AT, stands for EBM-AT or compatible). There were several hardware 
innovations during the refinement of the AT, such as high capacity floppy disk 
drives and access to additional memory (both are discussed later in this chapter). 

The nugority of software designed for use on the PC and XT can 
be used on the AT. Recently, software has been developed to exploit the 
capability of the 80286 processor. Specific applications for the AT will not be 
usable (wiU not be compatible) on the PC or XT. 
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CL Intel’s 80386 CPU (386) 

In the past two years Intel has been promoting a new CPU, the 
80386 processor. This processor has improved capabilities over the 80286 
processor. The computers that are built around this processor are commonly 
referred to as 386 machines. 386 computers are faster then AT machines. But 
the significant change that was introduced in the 386 was "multi-tasking". This 
is where more then one program can run at the same time. As with the 80286, 
the 386 is backward compatible, which means that it can execute programs that 
were designed for the PC, XT, and AT. Programs written explicitly for the 386 
will not be useable on the previous computers. 

2 . Computer Memory 

All computers have a set of transistors that are specially designed to 
store the electric voltages that represent the I’s and O’s for the computer to 
work from. On a micro-computer, machines have 640K (640,000 bytes) of 
memory, others with more and others with less. This number represents the 
number of transistors in the machine to temporarily store the instructions and 
data that was entered into the machine. 

When a program is loaded into a computer, the program is being 
loaded into memoiy, call Random Access Memory (RAM). When the operator 
nms a program (after it has been loaded into the computer) the instructions for 
the program are coming from the RAM and the data that is being enter is also 
being stored into the RAM. 

The amount of RAM needed depends on the software package that the 
operator decides to use and the amoimt of data that will be handled. Once the 
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operator knows what the appUcation requirements are, the operator should go to 
the Automated Data Processing Center within their command and ask for their 
advice. 

Note that RAM is temporary. When a machine is turned off, the 
program and data are lost. When a new application is loaded into the computer, 
the previous application and data will be removed. Permanent storage 
techniques are discussed next. 

3. Peripherals 

Peripheral are hardware components that are attached to the computer 
to perform some task. Peripherals fall into three categories: storage devices; 
input devices; and output devices. 

a. Storage Devices 

A storage device is any mechanism that is attached to a computer 
that makes it possible to save and reuse programs and data. There are several 
storage devices on the market. This docmnent will focus on the more common 
or soon to be common storage devices. All storage devices work on a basic 
technology of a tape recorder. By using the tape recorder as an example, an 
illustration as to how computers saves data can be made. 

A tape recorder works in the following manner; As the recorder 
picks up the music that is being played with the microphone, the tape recorder 
circuits codes the music into electronic signals. These electronic signals are sent 
to the recording head which in turn generates a magnetic field. This magnetic 
field, on the recorder head, changes as the signals change in respect to the 
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music. As the tape passes under the recorders head, the magnetic characteristics 
of the tape change. This change on the tape captures the magnetic signals. 

Due to the properties of the tape, the magnetic signal b retained 
on the tape for a lengthy period of time. The storage life of the recording is 
affected by the quality of the tape and how the tape is handled and stored. This 
is how music b saved and stored for futme use. 

For retrieving the data on the tape (in this case, the music) the 
process is reversed. The tape passes under the head of the recorder, and the 
head now senses the magnetic fields on the tape and transbtes these signals in 
signals that the recorder can understand. Now the recorder can recreate the 
music. 

The long term storage devices used in micro-computers are 
traditionally disk drives. They are called disk drives because of the storage 
medium used, it is in the shape of a round disk. All dbk drives use the same 
principles of operation. They store data much like the tape recorder but instead 
of having one continuous tape to record onto, the dbks are divided up into 
tracks, see Figure 2. These tracks work the same as a tape in the tape recorder, 
the difference b that when more tape is required, the recording head (read/write 
head) can travel (move) to another track to continue the save or read process. 

Over time, the technology used to develop and produce dbk drives 
improved. This technology has introduced various types of disk drives on the 
market. As a result, a user needs to be aware of the basic differences between 
them. 
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Illustration of a Computer Disk Drive 
and Disk 

Tracks 



Figure 2 Example of a Disk Drive and Disk 

Disk drives fall into three common categories, hard disk drive 
(also referred to as fixed disk or Winchester drives) which is permanently 
installed in the computer and can not be easily removed; floppy disk drives, and 
optical disk drives. 

(1) Hard Disk Drives Hard disk drives are traditionally installed 
internally to the computer. These are iwually not removable (there are a 
limited niunber of removable hard disk drives on the market but are not 
frequently used in the DoN). Hard disk drives receive their name from the 
type of recording medium used in them. Like all other disk drives, hard disk 
drives use a round disk (or several round disks layered on top of each other). 
The difference is that the disk is made out of hard metallic material versus a 
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floppy disk that is made of a flexible recording material. The properties of the 
hard disk drives make it possible to save far greater quantities of data compared 
to floppy disk drives. Hard disk drives have a storage capability ranging from 10 
million bytes of information up to several hundred million bytes of information 
(floppy disks have a capacity ranging from 360,000 to 1.4 million bytes). 

(2) Floppy Disk Drives Floppy disk drives received this label 
because of the flexible recording medium used. One of the primary advantages 
of floppy disk drives is that the recording medium is easily removable. This 
makes it possible to enter and store data at one micro-computer, save the data to 
the floppy disk, remove the floppy disk, then place the floppy disk into a 
different computer for retrieval of informa ti on. 

In the early 80’s the standard for floppy disk drives was a 5 
1/4" disk drive that had a storage capacity of 360,000 bytes of information (360K 
disk drive). By the mid 80’s a new 6 1/4" floppy disk drive was developed that 
had a storage capacity of 1.2 million bytes of information (often referred to as a 
"high density disk drive"). The technology of the high density disk drive internal 
components was improved and the high density 5 1/4" disks also had to be of a 
higher quality. The computer industry made it possible for the new High 
Density disk drives to be able to retrieve and store data on the 360K disks. But, 
due to the characteristics of the new high density disks and disk drives, it is not 
possible to retrieve and store data off a high density disk in a 360K disk drive 
(unless the high density disk is used as a 360K disk). 
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A second size floppy disk was developed in the mid 80’s, the 
3 1/2" floppy disk. This new disk and disk drive has a 720,000 byte storage 
capability (720K). This floppy disk resulted in a smaller and improved diskette. 
This diskette, unlike the flexible 5 1/4 " disk, is protected with an improved hard 
plastic casing. This disk is not compatible with either 5 1/4" disk drives. In the 
late 80’s, the 3 1/2" disk drive was also improved. A high density version of the 
3 1/2" disk drive was made available. This high density version has a 1.4 milli on 
byte storage capacity. And like the 5 1/4" drives, the high density 3 1/2" disk 
drives can use the 720K disks but the 720K disk drive can not read the data 
stored on the high density disks. 

(3) Optical Disk Drives The current state of the art in storage 
medium is in the area of optical disk drives. There are cxirrently two basic types 
of optical disk drives; the Compact Disk - Read Only Memory (CD-ROM) and the 
Write Once, Read Many (WORM). These disk drives use laser technology, much 
like the compact disk players. CD-ROM is more of a data repository. CD-ROM 
does not have the abUity to store information that is in the computer. As the 
ROM indicates. Read Only Memory, the computer can only access the compact 
disk and retrieve information from it. The information is traditionally provided 
for by a commercial or government sotu-ce that is used by more then one 
command. 

Unlike CD-ROM, the WORM disk drive has the abihty to 
store data that is in the computer much like a hard disk drive. The Worm disk 
drive has the ability to store approximately 500 million bytes of data. 
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6 . Input Devices 

An input device is anything that is attached to the computer that 
makes it possible to input data or a program into the computer. All input 
devices are similar in purpose but are quite different in appearance and use. 

The basic purpose of an input device is to convert data or information from one 
meditun, such as information on a document, into electronic signals that the 
computer can recognize and use. Then the device sends that signal to the 
computer for processing. To illustrate this, lets look at the most easily 
recognized input device, the keyboard, followed by a couple other input devices. 

(1) Keyboard A keyboard is an electronic device that sends 
electronic signals to the computer each time a key is pressed. Each time a key 
is pressed, the keyboard generates the proper group of I’s and O’s so that the 
computer recognizes that particular key stroke. There are a multitude of 
different keyboards that can be used on several different ^tems. The selection 
of the keyboard is primarily a matter of preference, as long as the keyboard is 
compatible with the system that it will be connected to. 

(2) Mouse A mouse is an input device that is primarily used as 
a semi-substitute for the keyboard. The mouse is a hand held device that is 
attached to the computer via a wire. The mouse is moved arotmd on the desk 
top which in turns moves a cursor or an arrow on the screen. By pressing a set 
of buttons on the mouse, the user is able to invoke some predetermined 
functions that woxild normally be invoked at the keyboard. The mouse was 
designed to make it easier for the user to select options or move items aroimd 
on the screen. The greatest strengths of a mouse is when it is used in a 
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graphics application. For use in applications that are ledger, data base, or word 
processing oriented, the use is traditionally limited to menu selections and 
highlighting text or numbers. 

(3) Optical Scanners Optical Scanners, also referred to as Bar 
Code Readers, are becoming more common in the business community. The 
device, which may he hand held or stationary, uses a light beam to analyze a 
series of lines that are specifically printed in a way that the scanner can read 
the coded item. This device is used in situations where there is a definable set 
of characters or niunbers that need to be entered into the computer many times 
over. With the use of bar code scanners, this eliminates the possibility of 
incorrectly entering the code into the computer by mistyping the code from the 
keyboard. This device is commonly used in the civilian sector and is currently 
being used in various parts of the Navy today. 

(4) Optical Character Reader The Optical Character Reader 
(OCR) is a device that can recognize characters and numbers on a piece of paper. 
The device scans the document and by use of both hardware and software, it is 
able to identify the data on the paper, convert the data to electronic signals, 
then finally send that signal to the computer. OCR’s are costly and if ever3rthing 
is not perfect on the document that is being scanned (in respect to how the 
scanner is setup) then the system is prone to error. 

(5) Modem A user may already have data that is electronically 
encoded, in that it has already been entered into another computer ^tem. A 
device called the Modem can bridge the gap between a local computer and a 
remote computer. A modem can connect the computer with the remote 
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computer via telephone lines (assuming that the remote computer is equipped 
with a modem, and can be made compatible with the users modem). 

A modem is a hardware device that is connected to the 
computer (it can be installed inside the computer or be installed external to the 
computer) and also connected to a telephone line. A modem, via use of software, 
has the ability to contact a remote computer, request the data that a user wants, 
and receive that data. The modem, with its software package handles the signal 
conversion over the telephones in a manner that is transparent to the user. The 
modem also has the capability of transmitting information to other computers, 
which makes the modem also an output device. 

CL Output Deoices 

An output device is anything that is attached to a computer that 
makes it possible for the computer to export data/information from the 
computer. Some easily recognizable output devices are printers, plotters, and 
monitors. These devices provide visible information to a user in the form of 
electronic display or paper type presentations. 

4. Operating System Software 

There are several different components to a computer, but how does 
the computer control these different pieces of hardware? How does it know 
when to piill data from a disk drive? How does the computer know where to go 
on the disk drive to save or retrieve the data? How does the computer know to 
look for input from the keyboard, mouse, scanner, or modem? And how does the 
computer know when to send something to the monitor or printer? The answer 
to all of these questions is in a software package called the Operating System. 





The operating system is specifically designed to handle these type of issues. 

Since a computer can only perform one task at a time, the operating system 
makes it possible for the computer to schedule and manage its tasks. The 
operating system monitors the requests placed upon the computer and handles 
the details of telling the computer what to do and when to do it. 

There are several different operating systems on the market. All of 
them are designed with special features and capabilities. The two that are 
widely used in Comptroller department micro-computers are Microsoft’s MS-DOS 
(Microsoft Disk Operating System) and IBM’s IBM-DOS, which is the same as 
MS-DOS except it is marketed by IBM, A third operating system is called OS/2, 
which stands for Operating System 2. OS/2 is being developed by Microsoft, and 
is the possible replacement for MS-DOS in the 80386 and newer CPU’s. 

Operating systems acts as the interface between the computer and 
application programs. Programs use the capabilities of the operating system to 
perform the low level tasks of managing the different parts of the computer 
system. This means that programs are written with a specific operating system 
in mind. So, if a user attempts to use a program xmder a different operating 
^stem then intended, the results are unpredictable. All software packages 
clearly specify which operating system it was intended for, 

5. Computer Programs and Data 

Computers must be told what to do, how to do it, and when to do it. 
Over the years, the effort that was reqiiired for the user/operator to provide the 
instructions to the computer to perform a task has been greatly reduced. This 
has been achieved though the development of computer programs (software). A 


94 












computer program is a series of instructions encoded in a manner that the 
computer can imderstand. Programs are written by trained people called 
programmers. Programmers create a program with a specific purpose in mind. 

With the advent of the micro-computer, thousands of programs have 
been written for both corporate and private use. Commercially available 
programs for micro-computers fall into two broad categories. First, programs that 
are designed for a specific task. The purchaser has a vety specific function that 
needs to be automated. The user has very little flexibihty in modifying the 
program to meet their desires. The following are some examples of this t}^e of 
programs: word processors; tax preparation packages; inventory control; 
telecommunication programs for commrmicating between different computers. 

The second category of software help a user develop an application 
that meets a specific need. Examples are: spreadsheet programs that give the 
user the ability to automate ledgers, track and manipulate figures, and present 
figures in a graphical maimer; database management programs which gives user 
the ability to efficiently store and retrieve various records/files within a 
computer system. 

Which type of program to select for use in a Comptroller’s department 
depends on the particular application that is being automated. To select the 
program to use, the user needs to address both the requirements and capacity of 
the system to be developed. Once this is known, it is best to consult with the 
staff in the local computer center for their recommendations. 
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